home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9611 / 000044_owner-urn-ietf _Tue Nov 5 21:33:25 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  5KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id VAA03645 for urn-ietf-out; Tue, 5 Nov 1996 21:33:25 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id VAA03640 for <urn-ietf@services.bunyip.com>; Tue, 5 Nov 1996 21:33:22 -0500
  3. Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA07127  (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 21:33:18 -0500
  5. Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
  6.           id VAA20653; Tue, 5 Nov 1996 21:33:00 -0500 (EST)
  7. Message-Id: <199611060233.VAA20653@ig.cs.utk.edu>
  8. X-Uri: http://www.cs.utk.edu/~moore/
  9. From: Keith Moore <moore@cs.utk.edu>
  10. To: Terry Allen <tallen@fsc.fujitsu.com>
  11. Cc: moore@cs.utk.edu, urn-ietf@bunyip.com
  12. Subject: Re: [URN] I18N does not belong in URNs 
  13. In-Reply-To: Your message of "Tue, 05 Nov 1996 16:57:00 PST."
  14.              <199611060057.QAA25635@ishtar.fsc.fujitsu.com> 
  15. Date: Tue, 05 Nov 1996 21:32:59 -0500
  16. Sender: owner-urn-ietf@services.bunyip.com
  17. Precedence: bulk
  18. Reply-To: Keith Moore <moore@cs.utk.edu>
  19. Errors-To: owner-urn-ietf@bunyip.com
  20.  
  21. > Keith Moore writes:
  22. > | Support for UTF-8 in URNs is a gross layering violation.  It also
  23. > | violates the requirements of RFC 1737 in several ways:
  24. > | 
  25. > | URNs are not intended to be meaningful to humans.  Rather, the desire
  26. > | for URNs to have a long lifetime indicates that they should not be
  27. > | human-friendly; otherwise, semantic drift will cause those names to
  28. > | need to be changed over time.
  29. > 
  30. > Our longest-lived names actually are meaningful to humans; to support
  31. > your argument you have to establish that semantic drift affects
  32. > names specifically (Moby Dick, Julius Caesar, Assurnasirpal) and
  33. > that using them in the context of a defined name space does not
  34. > insulate them from semantic drift.  
  35.  
  36. Names like those you quote are ambiguous.  There are different works
  37. named Moby Dick (not just the book by Melville; there are plays,
  38. screen plays, radio plays, parodies) and Julius Caesar (not just 
  39. the play by Shakespeare, but also biographies, screen plays, 
  40. and at least one symphony).  Ambiguous names aren't suitable as URNs.
  41.  
  42. > | URNs need to have global scope and to be transcribable.  Few people on
  43. > | this planet could accurately transcribe more than a small percentage
  44. > | of UTF-8.  Even those that could transcribe it could probably not type
  45. > | most UTF-8 characters on their keyboards.  It's also completely
  46. > | unacceptable to expect people to have a graphical display and hunt
  47. > | through character menus just to type in a URN.
  48. > 
  49. > Few people on this planet can accurately transcribe anything.  
  50.  
  51. That's not true.  People regularly transcribe telephone numbers, 
  52. email addresses, ISBNs, URLs, credit card numbers, etc. with 
  53. sufficient accuracy for their purposes.  But ask people to 
  54. transcribe identifiers in (say) Klingon, or to type them in 
  55. on a keyboard not designed for such, and you'll get much lower 
  56. accuracy.
  57.  
  58. > Your
  59. > last point would have merit were it not that we absolutely must
  60. > be able to grandfather in existing name spaces.
  61.  
  62. Yes, we must be able to grandfather existing name spaces *that serve
  63. similar purposes to URNs*.  ISBNs qualify.  Handles qualify.
  64. Usenet message-ids qualify.  But URNs don't have to handle existing
  65. name spaces that don't have the characteristics that URNs have.
  66. Offhand, I don't know of any name spaces that have such characteristics,
  67. that attempt to be human friendly.
  68.  
  69. > | URNs should not be in any language, not even English.  I would
  70. > | enthusiastically support requiring all URNs to be in a restricted
  71. > | character set or otherwise discourage human friendliness (though due
  72. > | to grandfathering requirements, each URN scheme would need its own
  73. > | rules for ensuring this).
  74. > 
  75. > That's an absolute show-stopper, if you are asking that existing
  76. > naming schemes develop encryption methods to transform their names
  77. > into unreadable strings.  People just won't do it because they
  78. > will see it as unreasonable and unnecessary.  
  79.  
  80. I don't think this is a problem, because I don't think existing URN-like
  81. name spaces are likely to be human friendly in the first place.  (If someone
  82. knows of a counterexample, please tell us.)
  83.  
  84. > We should be building the big tent that everyone can live under,
  85. > not trying to close out name spaces we don't like.  
  86.  
  87. Yes, and we should also be restricting the problem to something that has 
  88. a hope of a reasonable solution.  They're not mutually exclusive, but 
  89. over-reliance on the "one big tent" theory has caused the failure of 
  90. many protocols.
  91.  
  92. (Please note that assuming we can define I18N'ed URLs -- and there is 
  93. certainly a better case to be made for these then I18N'ed URNs -- I 
  94. would have no problem with this group defining resolution protocols that 
  95. can be used with them.  It's just that I18N isn't appropriate for the 
  96. URN name-space.  And I18N'ed URLs aren't in scope for this group.)
  97.  
  98. Keith